﻿<?xml version="1.0" encoding="utf-8" ?>
<html>
  <h3>Usage example</h3>
  <p>Load an image from a TIFF file.</p>
  <pre>
    TIFFCodec codec = new TIFFCodec();
    codec.setFile("image.tif", CodecMode.LOAD);
    codec.process();
    IPixelImage loadedImage = codec.getImage();
  </pre>
  <p>Saving images is not supported by this codec.</p>
  <h3>Compression types</h3>
  <h4>Reading</h4>
  <p>
    The TIFF package supports the following compression types when reading:
    <ul>
      <li>
        <em>Uncompressed</em>. Compression method number 1. Works with all types of image data. See {@link TiffCompressionNone}.
      </li>
      <li>
        <em>Packbits</em>. Compression method number 32773. Works with all types of image data. See {@link TiffCompressionPackbits}.
      </li>
      <li>
        <em>CCITT Group 3 1-Dimensional Modified Huffman runlength encoding</em>. Compression method number 2.
        Works with bilevel image data only. See {@link TIFFDecoderModifiedHuffman}.
      </li>
      <li>
        <em>Deflated</em>. Compression method number 8 or 32946. Works with all types of image data. See {@link TiffCompressionDeflate}.
      </li>
      <li>
        <em>LogLuv RLE</em> and <em>LogLuv 24</em>. Compression method numbers 34676 and 34677. Works only with LogLuv color data. See {@link TiffCompressionLogLuv}.
      </li>
    </ul>
  </p>
  <p>
    Note that you can write your own decoder (extending {@link TiffCompression}) for any compression type
    you want.
  </p>
  <h3>Image types</h3>
  <h4>Reading</h4>
  <p>
    The TIFF package supports the following image / color types when reading:
    <ul>
      <li>
        <em>Black &amp; white</em>. JIU image data type {@link net.sourceforge.jiu.data.IBilevelImage}.
      </li>
      <li>
        <em>Grayscale, 4 and 8 bits per pixel</em>. JIU image data type {@link net.sourceforge.jiu.data.Gray8Image}.
      </li>
      <li>TODO add other image types</li>
    </ul>
  </p>
  <p>
    Note that you can write your own decoder (extending {@link TiffCompression}) for any compression type
    you want.
  </p>
  <h4>Writing</h4>
  <p>
    Writing TIFFs is not supported.
    I don't know if or when it will be supported.
  </p>
  <h3>Strips and tiles</h3>
  <p>
    The early versions of TIFF considered an image to be a sequence of <em>strips</em>.
    Each strip was a rectangular part of the image, as wide as the complete image,
    and with a certain height defined by the <em>rows per strip</em> tag.
    So with a number of rows per strip of 10, and an image height of 200, you would
    have to store 20 strips.
    It was recommended that a strip should not be larger than 8 KB (RAM was tighter
    in those days).
    The rule of thumb to define the number of rows per strip was to see how many rows
    would fit into 8 KB.
  </p>
  <p>
    Later, the concept of <em>tiles</em> was added to the TIFF specs.
    Tiled TIFFs are separated into rectangles that not only had a defineable
    height but also a defineable width (tile width and tile height are also stored in
    corresponding tags).
  </p>
  <p>
    Obviously, strips are just a special case of tiles, with the tile width being equal
    to image width.
    That is why JIU internally only deals with tiles.
    The only difference: No row padding takes place for strips.
    In a tiled image with a tile height of 10 and an image height of 14,
    the image is two tiles high.
  </p>
  <h3>Number of images</h3>
  <p>
    TIFF allows for multiple images in a single file.
    This codec regards the image index, queries {@link #getImageIndex} and skips to the
    correct image.
  </p>
  <h3>Bounds</h3>
  <p>
    The bounds concept of JIU is supported by this codec.
    So you can specify bounds of a rectangular part of an image that you want to load
    instead of loading the complete image.
  </p>
  <h3>Color spaces</h3>
  <p>
    The following color spaces are understood when reading truecolor TIFF files.
    <ul>
      <li>
        <em>RGB</em> - should cover most truecolor files.
      </li>
      <li>
        <em>CMYK</em> - is supported, but colors may not be exactly right.
        CMYK data is converted to RGB on the fly, so the codec user never accesses CMYK data.
      </li>
      <li>
        <em>LogLuv</em> - is supported, but not all flavors yet.
      </li>
    </ul>
  </p>
  <h3>Physical resolution</h3>
  DPI information can be stored in TIFF files.
  If that information is available, this codec retrieves it so that it
  can be queried using {@link #getDpiX} and {@link #getDpiY}.
  *
  <h3>Background information on TIFF</h3>
  TIFF is an important image file format for DTP (desktop publishing).
  The advantages of TIFF include its flexibility, availability of libraries to read
  and write TIFF files and its good support in existing software.
  The major disadvantage of TIFF is its complexity, which makes it hard for software
  to support all possible valid TIFF files.
  <p>
    TIFF was created by Aldus and now <em>belongs</em> to Adobe, who offer a specification document:
    <a target="_top" href="http://partners.adobe.com/asn/developer/PDFS/TN/TIFF6.pdf">
      TIFF
      (Tagged Image File Format) 6.0 Specification
    </a> (updated on Web September, 20 1995,
    document dated June, 3 1992) (PDF: 385 KB / 121 pages).
  </p>
  <p>
    Other good references include the <a target="_top" href="http://www.libtiff.org">
      homepage
      of libtiff
    </a>, a free C library to read and write TIFF files and
    <a target="_top" href="http://home.earthlink.net/~ritter/tiff/">
      The Unofficial TIFF
      homepage
    </a> by Niles Ritter.
    Also see <a target="_top" href="http://dmoz.org/Computers/Data_Formats/Graphics/Pixmap/TIFF/">the TIFF section</a>
    of the <a target="_top" href="http://www.dmoz.org">Open Directory</a>.
  </p>
  <p>
    TIFF is used for various specialized tasks.
    As an example, see <a target="_top" href="http://www.remotesensing.org/geotiff/geotiff.html">GeoTIFF</a> (geographical
    data) or <a target="_top" href="http://www.ba.wakwak.com/~tsuruzoh/index-e.html">EXIF</a>
    (digital camera metadata; this is actually a TIFF directory embedded in a JPEG header).
  </p>
  <p>
    Here's a list of features that make TIFF quite complex:
    <ul>
      <li>More than one image can be stored in a TIFF file.</li>
      <li>Integer values that are larger than one byte can be in either little or big endian byte order.</li>
      <li>
        Various color types are supported (bilevel, gray, paletted, all kinds of color spaces (RGB / YCbCr / CMYK).
        It's easy to add new color types, so this list can grow.
      </li>
      <li>
        The meta data (information that describes the image and how it is stored) can be distributed all over
        the file.
      </li>
      <li>
        Image data is stored as packed bytes, 4-bit-nibbles, bytes and 16-bit-integers. Other types are possible
        as well.
      </li>
      <li>Various compression types are supported; not all types can be used on all color types.</li>
      <li>Image data can be stored in strips or tiles.</li>
      <li>An arbitrary number of non-image-data samples can stored within the image data.</li>
      <li>
        Color types with more than one sample per pixel can store data in an interleaved (<em>chunky</em>)
        way or in planes.
      </li>
      <li>Different ways of defining black and white are possible with bilevel and grayscale images.</li>
    </ul>
  </p>
</html>